The change seems useful indeed. Is this PR closed by accident @FFY00, or for some other reason?

Converting the module itself to JSON turned out to be a bit problematic, so I pivoted to simply adding a JSON file with the sysconfig data in GH-127302. Though, in GH-127430, a followup to that PR, I fixed some of the issues I was running into earlier, so we may be able to revisit this PR.

Thanks for the context!

Is there anything still outstanding which would prevent us from making the JSON file the single source of truth? Distributing the same information in two different formats will inevitably lead to confusion. From the perspective of cross-compiling packages for mobile, if the JSON file isn't going to be used, then I'd prefer if it wasn't there at all.

It's an implementation detail, so you could remove it if desired. The installed JSON file is just a reference output of sysconfig.get_config_vars() on the base (non-venv) environment, which is a bit different from converting the data module to JSON, as proposed in this PR, so the semantics are quite different. It is simply meant to help users that can't execute the interpreter to make better assumptions (eg. build systems during cross compilation), but it should not be regarded as a source of truth, or a replacement for sysconfig.get_config_vars(). This is why it is an implementation detail, rather than a stable interface.

build-details.json (from PEP 739), OTOH, is meant to be a source of truth.

The problem is, if external build systems do start using it (which they probably will once they notice it, whether we encourage them to or not), then removing it will no longer be an option. So any tool which needs to alter this data (as we're doing for Android and iOS in cibuildwheel), will have no choice but to alter it in both files.

I guess I'm just not clear about what the purpose of this file is. You say it's "meant to help ... build systems during cross compilation", but the general principle is that anything starting with an underscore should not be used externally at all.